I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

Yes, fixing the end of line whitespaces in the markdown files is welcomed. I would do it in a separate PR from the infrastructure changes to enable markdown lint.

Tagging subscribers to this area: @ViktorHofer
See info in area-owners.md if you want to be subscribed.

@Youssef1313, is this PR still relevant at this point, or should it be closed?

Should be closed I think given that the repo doesn't allow GitHub Actions.

@Youssef1313 We now use at least one github action in dotnet/runtime so feel free to reopen. We should be able to get this in.

@Youssef1313 We now use at least one github action in dotnet/runtime so feel free to reopen. We should be able to get this in.

That's great!

We should also delete https://github.com/dotnet/runtime/blob/master/docs/issues-pr-management.md#what-is-dotnetruntimes-policy-on-gitactions then.

@jkotas I'll delete that section and fix the new markdown violations.

Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:

1. Azure Pipelines

These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check.

Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:

1. Azure Pipelines

These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check.

Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:

1. Azure Pipelines

These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check.

summarizing discussion with @ViktorHofer - I removed the "push" section, so that this only runs on PR's, and does not trigger a Node install on rolling builds/CI. Our official builds, which produce shipping bits, do not run in Github pipelines, so this should not trigger Node there, regardless.

Apologies, I am afraid I am encountering technical difficulties that might have hampered my ability to assist with merging this pull request. I will continue to try to assist if there are further changes to this pull request.

Thanks for the contribution @Youssef1313

@danmosemsft Does this mean that changes to markdown files can lead to PR test failures? That seems extremely unnecessary.

@BruceForstall In retrospect I agree (my focus was on just getting this PR finished as I observed it was old). I think this step is low value, although perhaps more rules could be enabled like checking for broken links.

@safern is looking to see whether we can make this rule only trigger for markdown changes -- then if someone somehow checks in bad markdown, it won't affect 99% of PR's. Is that reasonable?

@safern is looking to see whether we can make this rule only trigger for markdown changes

This is already the case.
This workflow is only run when there are changes in md files.

@danmosemsft Does this mean that changes to markdown files can lead to PR test failures? That seems extremely unnecessary.

Only if the PR has bad markdown changes only.

Also note that if it does fail on a markdown edit, it fails within moments of pushing to the PR, so you don't waste an hour or two waiting for the jobs to complete.

As mentioned, my care level about spacing is low, but there are more interesting rules (I have hand-fixed many broken links in the past and would rather not)

@safern is looking to see whether we can make this rule only trigger for markdown changes -- then if someone somehow checks in bad markdown, it won't affect 99% of PR's. Is that reasonable?

It would have no effect, since if you don't PR markdown and the rule doesn't fire, it won't have anything to complain about. Anything with markdown will be subject to the rule.

Your broken link example would be useful, but what if a link went away (even transiently) and my unrelated markdown change got flagged (well, assuming the rule applied to all markdown, not just the changed one). That would be annoying. And if it doesn't check all existing md for missing links, then there's no value anyway.

The question is whether we want to validate markdown at all. I hope we encourage markdown / documentation writing and don't discourage it in any way -- don't make it subject to the vagaries / flakiness of the CI system, for example, or make me wait for the CI to complete before merging.

One improvement would be if a markdown-only change only did markdown testing and nothing else.

It would have no effect, since if you don't PR markdown and the rule doesn't fire, it won't have anything to complain about. Anything with markdown will be subject to the rule.

The case I was concerned about was where a markdown error got in somehow and then breaks all PR jobs, who care nothing about markdown. It sounds like that won't happen.

One improvement would be if a markdown-only change only did markdown testing and nothing else.

It does this already. I verified that yesterday. It's a rather nice experience - 2 mins from PR to green.

Yep, the action is configured to only run when md files are changed:

@Youssef1313 do you have any interest in following up to enable more useful rules, like for broken links, malformed tables and headings, etc? I have spent my share of time fixing those things in the past. I would expect we could merge that PR much more quickly than this one as we already have the build step now.

@Youssef1313 thanks a lot for your contribution. +1, it would be fantastic to have more rules enabled.

Sure, would be glad to help. May take a while though due to university exams starting next week :/